\section{Introduction}
\label{sec_introduction}

Integrating security mechanisms into applications is necessary to ensure data confidentiality, data integrity and users' privacy preservation. Security is however a cross-cutting concern affecting most parts of an application and, therefore, decoupling security requirements from the code implementing system functionalities is desirable to achieve code modularity and simplify the correct development of systems and their maintenance. 
%However, security is a cross-cutting concern affecting most parts of an application. Therefore, in order to achieve code modularity and simplify the development of correct systems and their maintenance, it is highly desirable to decouple the security requirements from the code implementing the system functionalities
%Previous contributions primarily focused on the separate specification of \emph{access control requirements} and their integration mechanisms into applications using either \emph{Aspect Oriented Programming} (AOP) \cite{Kiczales1997} (\cite{Erlingsson2000,Bauer2005,DeOliveira2007,Hamlen2008,Hussein2012}, among others) or a model-based approach (e.g., \cite{Mouelhi2008,Morin2010a,Basin2011}). 
Previous works primarily focus on the separate specification of \emph{access control requirements} and integration of access control enforcement mechanisms into applications using either \emph{Aspect Oriented Programming} (AOP) \cite{Kiczales1997} \cite{Erlingsson2000,Bauer2005,DeOliveira2007,Hamlen2008,Hussein2012} or using a model-based approach \cite{Mouelhi2008,Morin2010a,Basin2011}. 
In the former approach, access control enforcement mechanisms are automatically \emph{weaved} into the application at compilation time, whereas in the latter approach, the system and its access control requirements are abstractly specified using \emph{models}, from which implementation code is generated. Neither of these approaches allows for the \emph{runtime} updating of security requirements.

%The dynamic nature of modern applications and their sophistication requires more than just \emph{static} access control, because they reflect regulatory and internal mandates that are naturally dynamic and evolving over time. However, the only security requirements covered in the previous approaches are mainly static (cf. Section \ref{sec:RW} for a detailed discussion of the current approaches and their features). On the other hand, many systems today have requirements that go beyond access control: \emph{usage control} \cite{Park2004} extends traditional access control by enabling specification of obligations that users must fullfill before, while or after accesses, and \emph{privacy obligations} \cite{Mont2004a,Ni2008}. \moussa{Explain in a few words what this consists of...}


The dynamic nature of modern applications and their sophistication requires however more than just \emph{static} access control, typically the only security requirement covered in existing approaches (see Section 6 for a detailed discussion of current approaches and their features). In particular, security requirements typically reflect regulatory and internal mandates, which are naturally dynamic and could change with time. Also, many systems today have requirements that go beyond access control such as usage control~\cite{Park2004}, which extends traditional access control by enabling specification of obligations that users must fullfill before, while or after access, and privacy obligations \cite{Mont2004a,Ni2008}, which dictate duties and expectations on how users' personal data should be handled.


%In this paper, we propose a Domain Specific modeling Language (\textsc{Dsl}) and an architecture for securing Java-based business applications that can handle dynamicity and more various security concerns. The \textsc{Dsl} supports the expression of fine-grained contextual authorization, obligation, sanction and reaction policies, thus covering many of the sophisticated security requirements of modern applications. Security policies specified using our \textsc{Dsl} are enforced into target applications using an application-independent architecture that follows the Policy Enforcement Point (PEP) / Policy Decision Point (PDP) paradigm. Our architecture enforces security requirements into target applications in a non-intrusive manner using Aspect-Oriented Programming (\textsc{Aop}) \cite{Kiczales1997}, enabling a clean separation between the application's functional and non-functional requirements. Furthermore, the architecture supports the update of security requirements at runtime. 
 
In this paper, we propose a Domain Specific modeling Language (\textsc{Dsl}) and an architecture for securing Java-based business applications to address the aforementioned issues. The \textsc{Dsl} supports the expression of fine-grained contextual authorization, obligation, sanction and reaction policies, thus covering the expression of many of the sophisticated security requirements of modern applications. Security policies specified using the \textsc{Dsl} are enforced into target applications using an application-independent architecture, which follows the Policy Enforcement Point (PEP) / Policy Decision Point (PDP) paradigm. The proposed architecture enforces security requirements into target applications in a non-intrusive manner using Aspect-Oriented Programming (\textsc{Aop}) \cite{Kiczales1997}, enabling a clean separation between the application's functional and non-functional requirements. Furthermore, the architecture supports the update of security requirements at runtime.  
 
%Paper outline
The remainder of the paper is organized as follows. Section \ref{sec:Approach} describes \SAR (for \emph{Security@Runtime}), our \textsc{Dsl} for dealing with the identified challenges and its enforcement architecture. Section~\ref{sec:Application-Example} illustrates our approach by presenting a complete application example. Section \ref{sec:Implementation} describes the implementation of our tool prototype. Section \ref{sec:Validation} shows performance results of the prototype for two real-life systems. Section \ref{sec:RW} presents related work; and Section~\ref{sec:Conclusion} concludes the paper and discusses future work.

